Inline media block by busbyk · Pull Request #968 · NWACus/web

busbyk · 2026-03-03T22:57:13Z

Description

Adds a new InlineMedia inline block for the Lexical rich text editor, allowing editors to embed images directly within text flow. Images can be positioned inline with configurable vertical alignment, or floated left/right with text wrapping.

Related Issues

None, alternative to #961

Key Changes

New InlineMedia block (src/blocks/InlineMedia/) — config and component for inline media in rich text
Position options: Inline (within text flow) or float left/right (text wraps around image)
Size options: Original (natural size), percentage widths (25%/50%/75%/100%), or fixed pixel height
Vertical alignment: Top, middle, bottom, or baseline (only for inline position)
Optional caption: Displayed below the image as small gray text
Registered in Posts collection and default Lexical editor config as an inlineBlock
RichText renderer updated with JSX converter for frontend rendering

How to test

Run pnpm dev and navigate to the admin panel
Create or edit a Post (or any content using the default Lexical editor)
In the rich text editor, use the inline block inserter to add an "Inline Media" block
Upload or select a media item and configure position, size, and alignment
Verify:
- Inline position: Image renders within the text line with correct vertical alignment
- Float left/right: Image floats to the side with text wrapping around it
- Size options: Percentage widths scale relative to the container; fixed height respects the pixel value
- Caption: Appears as small text below the image when provided
View the published content on the frontend to confirm the rich text JSX converter renders correctly

Screenshots / Demo video

https://www.loom.com/share/a167f8e500824d60b88914fe6b66014b

Hmm I wonder if floats are too confusing to content editors when they can use them, unconstrained in the ContentBlock?

Migration Explanation

No migration needed — this adds a new inline block type to existing Lexical rich text fields. Existing content is unaffected.

Future enhancements / Questions

Could extend to support inline video embeds
May want to add margin/padding controls for finer spacing adjustments around floated images
Thumbnails for inline blocks don't seem to work. We likely need to open a PR in Payload for this. I've left imageUrl in the block config using the same MediaThumbnail.jpg for when that gets fixed.
Images are still not exactly responsive - if we set a percentage width that width gets used at all screen sizes. Same problem as Media block should use responsive image sizes based on it's container #757. Will fix this block in that issue as well.

Introduces a new inline block for embedding images within rich text content. Supports float left/right with text wrapping and inline positioning with configurable vertical alignment. Registered in defaultLexical and Posts collection. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

…ible caption Replace small/medium/large presets with more flexible sizing options: original, 25/50/75/100% container width, and fixed pixel height. Caption now renders as visible text below the image instead of a tooltip. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

github-actions · 2026-03-03T23:32:04Z

Preview deployment: https://inline-media-block.preview.avy-fx.org

Create a shared DEFAULT_INLINE_BLOCKS constant (mirroring DEFAULT_BLOCKS pattern) and register it in all BlocksFeature configs so InlineMedia is available in Content, Callout, BlogList, HomePages, and Events editors. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Reuse the existing MediaBlock thumbnail for the inline media block inserter. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

defaults.ts imports block configs (e.g. BlogListBlock), and those block configs now import DEFAULT_INLINE_BLOCKS from defaults.ts, creating a circular dependency. Move DEFAULT_INLINE_BLOCKS to a separate defaultInlineBlocks.ts file to break the cycle. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

rchlfryn

A lot of thinking out loud as review notes in the PR. Take em or leave em.

To answer your question about having both this and the ImageBlock, I think we should have both and get feedback from users on which makes more sense. I could see users wanting more inline blocks.

rchlfryn · 2026-04-08T17:16:38Z

src/blocks/InlineMedia/config.ts

+      defaultValue: 'inline',
+      options: [
+        { label: 'Inline', value: 'inline' },
+        { label: 'Float left', value: 'float-left' },


Interesting - for some reason I thought we were using camel case for values, but every other value is one word.

Maybe update the labels to just be Left and Right? I am not sure float is needed here.

Cool, I'm down for the label change - updated the description too: 61ba101

Interesting - for some reason I thought we were using camel case for values, but every other value is one word.

I almost always default to using snake case for unique values like keys like this or slugs. Just my preference 🤷‍♂️

rchlfryn · 2026-04-08T17:32:21Z

src/blocks/InlineMedia/Component.tsx

+      className="block [&>span]:h-full [&_picture]:h-full [&_picture]:my-0"
+      style={{ height: `${fixedHeight}px` }}
+    >
+      <Media htmlElement="span" resource={media} imgClassName={imgSizeClass} sizes={sizes} />


Any reason to not include pictureClassName="my-0" here?

Ah no, good call: 4b352f3

rchlfryn · 2026-04-08T17:34:56Z

src/blocks/InlineMedia/config.ts

+        { label: '25% width', value: '25' },
+        { label: '50% width', value: '50' },
+        { label: '75% width', value: '75' },
+        { label: '100% width', value: '100' },


I don't think it matters, but maybe we add a w in front of of each value to ensure it's a string. Doesn't seem to be an issue.

I like the idea, to make it clear that these are strings but we actually use these for the sizes attribute in the component so we'd have to strip off the 'w' prefix which I think would be more confusing.

rchlfryn · 2026-04-08T17:43:04Z

src/blocks/InlineMedia/Component.tsx

+    sizes = `${resolvedSize}vw`
+  } else if (isFixedHeight) {
+    imgSizeClass = 'h-full w-auto'
+    sizes = '96px'


How is this being calculated/ is it needed?

This is the attribute — a hint that tells the browser which source to pick from a responsive srcset before layout is known. For fixed-height images the rendered width depends on the image's aspect ratio, which we don't have at render time without reading the media dimensions. 96px is a conservative fallback so the browser doesn't load the full-resolution source. It's imperfect but errs on the side of a smaller download; the browser will still render at the correct size.

rchlfryn · 2026-04-08T17:44:57Z

src/blocks/InlineMedia/Component.tsx

+  const mediaElement = isFixedHeight ? (
+    <span
+      className="block [&>span]:h-full [&_picture]:h-full [&_picture]:my-0"
+      style={{ height: `${fixedHeight}px` }}


⛏️ You could make this a class name like you are above and remove the inline style.

fixedHeight is dynamic so we can't use a classname here. See https://tailwindcss.com/docs/detecting-classes-in-source-files#dynamic-class-names:~:text=Don%27t%20use%20props%20to%20build%20class%20names%20dynamically

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

The non-fixed-height path already passed this prop directly. The fixed-height path was achieving the same effect via a descendant selector, which was inconsistent. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

busbyk and others added 4 commits March 3, 2026 11:54

removing as const

dd16847

Merge branch 'main' into inline-media-block

47ad611

busbyk had a problem deploying to Preview March 3, 2026 23:10 — with GitHub Actions Error

busbyk temporarily deployed to Preview March 3, 2026 23:10 — with GitHub Actions Inactive

fixing types

1903e72

busbyk temporarily deployed to Preview March 3, 2026 23:14 — with GitHub Actions Inactive

busbyk temporarily deployed to Preview March 3, 2026 23:15 — with GitHub Actions Inactive

busbyk self-assigned this Mar 7, 2026

busbyk mentioned this pull request Apr 6, 2026

Document References Extraction System #1025

Open

busbyk and others added 4 commits April 6, 2026 14:08

Add thumbnail to InlineMediaBlock config

ac35d98

Reuse the existing MediaBlock thumbnail for the inline media block inserter. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Merge branch 'main' into inline-media-block

1827a03

busbyk temporarily deployed to Preview April 6, 2026 23:12 — with GitHub Actions Inactive

busbyk marked this pull request as ready for review April 6, 2026 23:15

busbyk requested a review from rchlfryn April 6, 2026 23:15

rchlfryn requested changes Apr 8, 2026

View reviewed changes

busbyk and others added 2 commits April 9, 2026 11:23

Update position labels to 'Left'/'Right' and simplify description

61ba101

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

busbyk had a problem deploying to Preview April 9, 2026 19:23 — with GitHub Actions Error

updated types

dd99700

busbyk temporarily deployed to Preview April 9, 2026 19:27 — with GitHub Actions Inactive

busbyk requested a review from rchlfryn April 9, 2026 19:39

Conversation

busbyk commented Mar 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Related Issues

Key Changes

How to test

Screenshots / Demo video

Migration Explanation

Future enhancements / Questions

Uh oh!

github-actions bot commented Mar 3, 2026

Uh oh!

rchlfryn left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

busbyk commented Mar 3, 2026 •

edited

Loading